【レポート】AWS Summit Tokyo 2017：AWS Greengrass Deep Dive #AWSSummit

AWS Summit Tokyo 2017

#レポート

#AWS IoT Greengrass

#AWS

せーの

2017.06.01

この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。

aws-summit-tokyo-2017-longlogo 2017年05月30日(火)〜2017年06月02日(金)の計4日間に渡り、グランドプリンスホテル新高輪品川プリンスホテルアネックスタワーで行われている『AWS Summit Tokyo 2017』。

当エントリでは2017年05月31日に行われた『AWS Greengrass Deep Dive』に関する内容をレポートしたいと思います。

AWS Summit Tokyo 2017（2017年5月30日～6月2日）｜AWS

セッション概要

当セッションの登壇者及び概要は以下の通り。

スピーカー：
　Craig Williams氏 Partner Solutions Architect, IoT Specialist Amazon Web Services, Inc.

セッション概要：
　IoT のシステムを構築する上でエッジコンピューティングに注目が集まっております。
　AWS が提供するエッジコンピューティングサービスとして、re:Invent 2016 にて AWS Greengrass が発表されました。
　本セッションでは、AWS Greengrass の紹介とGreengrassを利用する上での技術情報をお届けします。

セッションレポート

多くの機械が発生したデータはクラウドに上がっていない
鉱山のような厳しい環境
遠隔から、例えば火星から集めたデータ
医療機器のデータ
これらはエッジで処理する必要がある

Greengrassが生まれた背景

3つの問題

物理的
- レイテンシ
- 1ms以下での処理が必要な場合がある
- コマンド＆コントロールに対応
経済的
- 大量のデータをクラウドに送信するコスト
- エッジで処理をし、フィルタリングをしてその一部をクラウドに送信する
地域的
- プライバシーの規制が地元当局で規制されている場合がある
- 医療の情報は病院の中に留める、といった規則もある
- 施設の中にとどめて匿名化してからクラウドにあげる

IoTにおける3つのレイヤ

Things
- デバイス
Cloud
- 情報を集める先
Intelligence
- 機械学習のアルゴリズムがデータを処理してクラウドに送り返す

AWS IoT

Device Gateway
- 認証システムは相互証明書。デバイスとクラウドは証明書を持つ必要がある。
- それぞれのセキュリティポリシーと1対1のマッピングを行う
- AWS SDKがなくてもAWS IoTにつなぐことは出来る
- MQTTのようなオープンソースをベースにしているのでロックインの心配もない
Rule Engine
- データがどこに繋がるのかを決める所
Device State
- Device ShadowはDeviceのState（状態）を持っている
- 8kのデータブロック。非構造のJSON
- Wi-Fiがあっても接続が切れることはよくある。オンラインになったときにコマンド＆コントロールが行われる

AWS Greengrass

サービスをエッジに拡張するもの
同じ機能を使ってエッジで運用が出来る
Device Gateway、Lambda Actionがエッジまでおりてきている
一元的にLambda関数をデプロイし、管理することが出来る
コンテナベースなので提供した仕組みをそのまま使うことができる
証明書が必要なこともAWS IoTと同じ
Device Stateもエッジにある
Greengrass自体はクラウドと通信出来る

メリット

ローカルイベントを早くレスポンスできる
オフラインでの運用
- AWSには5年に一度接続できればいい
- Lambdaのデプロイ等は自動的にGreengrassが受け取り更新する
シンプルなデバイスプログラミング
- Cronジョブ、ロギングなどのローカルプログラミングにおける課題はGreengrassで一気に解決される
- 開発者はただコードを書くだけでよい
IoTアプリケーションのコストを削減
- 帯域の使用量が違う
- 開発期間が短くなる

GGC (Greengrass Core)

Greengrassはソフトウェア
- Lambdaの実行、メッセージ、Device shadow、クラウドとの直接連携に責任をもっている
- Lambdaはコンテナエンジンによって動く
- これらは全てGGCによって管理されている

対象ハードウェア

1GHzのcore
128MB RAM
x86 and ARM
Linux(Ubuntu or Amazon)
Raspberry Piでも動く
コンテナベースのエンジンがどんなハードウェアでも動くように設計されている

SDK

IoT Device SDKを利用するとローカルネットワークを介してGGCと通信する設定ができる
独自の証明書を使う。
初回起動時GGCが証明書、エンドポイントの取得を行う

Greengrass Group

全てのGGCとその他のデバイスのコミュニケーションに関する設定セット
Shadowをローカルにするかクラウドに同期するかを選択できる
Lambda Funcitonのリスト(クラウドからレプリケーションしたいリスト)を設定する

ローカルルールエンジン

Rule Engineと同じ
データがコアからクラウドに流れて欲しい、という場合にGreengrass Groupがその流れを管理する

Group + Deploymentsのメリット

例えば工場の中にGroupがそれぞれあり、それぞれのデータの流れを独自に制御する
ルーティングの構成などをわざわざ現場に行かなくても管理できる

Local Lambda

Python2.7をサポート
将来言語を増やしていく予定
これまでと同じようにコードを書いてzip化してアップロードしてLambda Functionを作成する

何が出来るか

コマンド＆コントロール
オフライン実行
データのフィルタリングと集約。帯域を節約
時間が経つとスマートに（機械学習)

Shadow

デバイスとLambdaの状態を示すJSONドキュメント
定義する内容は論理的なもの(車、エンジンなど）
クラウドに同期することもローカルに保持することも可能
他のシステム(携帯など）で見たい場合は同期させればよい

Messaging

エッジでは全てのトランザクション、データの流れは定義される必要がある
メッセージングの流れ
- Identityを確認
- ルートテーブルの確認 => ターゲットのマッチ、デフォルト拒否
- LambdaかSubscriberへデータを流す
ルートテーブルに明示的な定義が無ければデータは受信できない
メッセージの内容をルートテーブルが見てどのLambdaを立ち上げるかどうか決める